Internet Engineering Task Force (IETF) C. Bormann 
Request for Comments: 7400 Universitaet Bremen TZI 
Category: Standards Track November 2014 
ISSN: 2070-1721 
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Abstract 
RFC 6282 defines header compression in 6LOWPAN packets (where 
"GLOWPAN" refers to "IPv6 over Low-Power Wireless Personal Area 
Network"). The present document specifies a simple addition that 
enables the compression of generic headers and header-like payloads, 
without a need to define a new header compression scheme for each 
such new header or header-like payload. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
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Introduction 
.1. The Header Compression Coupling Problem 


[RFC6282] defines a scheme for header compression in 6LoWPAN 
[RFC4944] packets; in this document, we refer to that scheme as 
6LoWPAN Header Compression, or 6LoWPAN-HC (where "6LoWPAN" refers to 


"IPv6 over Low-Power Wireless Personal Area Network"). As with most 
header compression schemes, a new specification is necessary for 
every new kind of header that needs to be compressed. In addition, 


[RFC6282] does not define an extensibility scheme like the Robust 
Header Compression (ROHC) profiles defined in ROHC [RFC3095] 
[RFC5795]. This leads to the difficult situation in which 6LoWPAN-HC 
tended to be reopened and reexamined each time a new header receives 
consideration (or an old header is changed and reconsidered) in the 
6LoWPAN/roll/CoRE cluster of IETF working groups. Although [RFC6282] 
was finally completed and published, the underlying problem remains 
unsolved. 


The purpose of the present contribution is to plug into [RFC6282] as 
is, using its Next Header Compression (NHC) concept. We add a 
slightly less efficient, but vastly more general, form of compression 
for headers of any kind and even for header-like payloads such as 
those exhibited by routing protocols, DHCP, etc.: Generic Header 
Compression (GHC). The objective is an extremely simple 
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specification that can be defined on a single page and implemented in 
a small number of lines of code, as opposed to a general data 
compression scheme such as that defined in [RFC1951]. 


1.2. Compression Approach 


The basic approach of GHC’s compression function is to define a 
bytecode for LZ77-style compression [LZ77]. The bytecode is a series 
of simple instructions for the decompressor to reconstitute the 
uncompressed payload. These instructions include: 


o appending bytes to the reconstituted payload that are literally 
given with the instruction in the compressed data 


o appending a given number of zero bytes to the reconstituted 
payload 


o appending bytes to the reconstituted payload by copying a 
contiguous sequence from the payload being reconstituted 
("backreferencing") 


o an ancillary instruction for setting up parameters for the 
backreferencing instruction in "decompression variables" 


o a stop code (optional; see Section 3.2) 


The buffer for the reconstituted payload ("destination buffer") is 
prefixed by a predefined dictionary that can be used in the 
backreferencing as if it were a prefix of the payload. This 
predefined dictionary is built from the IPv6 addresses of the packet 
being reconstituted, followed by a static component, the "static 
dictionary". 


As usual, this specification defines the decompressor operation in 
detail but leaves the detailed operation of the compressor open to 
implementation. The compressor can be implemented as with a 
classical LZ77 compressor, or it can be a simple protocol encoder 
that just makes use of known compression opportunities. 


1.3. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
RFC 2119 [RFC2119]. 


The term "byte" is used in its now-customary sense as a synonym for 
"octet". 
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Terms from [RFC7228] are used in Section 5. 
1.4. Notation 


This specification uses a trivial notation for code bytes and the 
bitfields in them, the meaning of which should be mostly obvious. 
More formally, the meaning of the notation is as follows: 


Potential values for the code bytes themselves are expressed by 
templates that represent 8-bit most-significant-bit-first binary 
numbers (without any special prefix), where 0 stands for 0, 1 for 1, 
and variable segments in these code byte templates are indicated by 
Sequences of the same letter, such as kkkkkkk or ssss, the length of 
which indicates the length of the variable segment in bits. 


In the notation of values derived from the code bytes, 0b is used as 
a prefix for expressing binary numbers in most-significant-bit-first 
notation (akin to the use of 0x for most-significant-digit-first 
hexadecimal numbers in the C programming language). Where the above- 
mentioned sequences of letters are then referenced in such a binary 
number in the text, the intention is that the value from these 
bitfields in the actual code byte be inserted. 


Example: The code byte template 
101nssss 


stands for a byte that starts (most-significant-bit-first) with the 
bits 1, 0, and 1, and continues with five variable bits, the first of 
which is referenced as "n" and the next four of which are referenced 
as "ssss". Based on this code byte template, a reference to 


ObOssss000 


means a binary number composed from a zero bit; the four bits that 
are in the "ssss" field (for 101nssss, the four least significant 
bits) in the actual byte encountered, kept in the same order; and 
three more zero bits. 


2.  6LoWPAN-GHC 


The format of a GHC-compressed header or payload is a simple 
bytecode. A compressed header consists of a sequence of pieces, each 
of which begins with a code byte, which may be followed by zero or 
more bytes as its argument. Some code bytes cause bytes to be laid 
out in the destination buffer, and some simply modify some 
decompression variables. 
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At the start of decompressing a header or payload within an L2 packet 
(= fragment), the decompression variables "sa" and "na" are 
initialized as zero. 


The code bytes are defined as follows (Table 1): 


p---------- 4------------------2-2---2-------2---2------------- p---------- + 
| code | Action | Argument | 
| byte | | | 
+---------- +------------------------ -- - 5-5 = +---------- + 
| Okkkkkkk | Append k = ObOkkkkkkk bytes of data in the | k bytes | 
| | bytecode argument (k < 96) | of data | 
| 1000nnnn | Append 0b0000nnnn+2 bytes of zeroes | 
| 10010000 | stop code (end of compressed data; see | 
| | Section 3.2) | | 
| 101nssss | Set up extended arguments for a | 
| | backreference: sa += 0b0ssss000, | 
| | na += 0b0000n000 | | 
| linnnkkk | Backreference: n = na-*0b00000nnn-*2; | 
| | s = 0b00000kkk+sa+n; append n bytes from | 
| | previously output bytes, starting s bytes | 
| | to the left of the current output pointer; | 
| | set sa = 0, na = 0 | | 
+---------- +---------------------- -- == 5 = +---------- + 


Table 1: Bytecodes for Generic Header Compression 
Note that the following bit combinations are reserved at this time: 
o Ollxxxxx 
o 1001nnnn (where 05b0000nnnn > 0) 
For the purposes of the backreferences, the expansion buffer is 
initialized with a predefined dictionary, at the end of which the 
reconstituted payload begins. This dictionary is composed of the 
Source and destination IPv6 addresses of the packet being 
reconstituted, followed by a 16-byte static dictionary (Figure 1). 
These 48 dictionary bytes are therefore available for backreferencing 
but not copied into the final reconstituted payload. 


16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 


Figure 1: The 16 Bytes of Static Dictionary (in Hex) 
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Su Integrating 6LoWPAN-GHC into 6LoWPAN-HC 
6LoWPAN-GHC plugs in as an NHC format for 6LoWPAN-HC [RFC6282]. 
3.1. Compressing Payloads (UDP and ICMPv6) 


By definition, GHC is generic and can be applied to different kinds 
of packets. Many of the examples given in Appendix A are for ICMPv6 
packets; a single NHC value suffices to define an NHC format for 
ICMPv6 based on GHC (see below). 


In addition, it is useful to include an NHC format for UDP, as many 
header-like payloads (e.g., DHCPv6, Datagram Transport Layer Security 
(DTLS)) are carried in UDP. [RFC6282] already defines an NHC format 
for UDP (11110CPP). GHC uses an analogous NHC byte formatted as 
shown in Figure 2. The difference to the existing UDP NHC 
Specification is that for 11010CPP NHC bytes, the UDP payload is not 
supplied literally but compressed by 6LoWPAN-GHC. 


0 1 2 3 4 5 6 1 
*R--—4R---4---4---4---4---4---4---—4 
kt Moe i El, CES 
4+---4---4---4---+4---+4---+---+---+ 


Figure 2: NHC Byte for UDP GHC (11010CPP) 


To stay in the same general numbering space, we use 11011111 as the 
NHC byte for ICMPv6 GHC (Figure 3). 


0 1 2 3 4 5 6 7 
4+---4---4---4---+4---+4---+---+---+ 
EE EI EES EEN 
+---4---4---4---+4---+4---+---+---+ 


Figure 3: NHC Byte for ICMPv6 GHC (11011111) 
3.2. Compressing Extension Headers 


Compression of specific extension headers is added in a similar way 
(Figure 4) (however, probably only Extension Header ID (EID) 0 to 3 
[RFC6282] need to be assigned). As there is no easy way to extract 
the Length field from the GHC-encoded header before decoding, this 
would make detecting the end of the extension header somewhat 
complex. The easiest (and most efficient) approach is to completely 
elide the Length field (in the same way NHC already elides the Next 
Header field in certain cases) and reconstruct it only on 
decompression. To serve as a terminator for the extension header, 
the bytecode 0b10010000 has been assigned as a stop code. Note that 
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the stop code is only needed for extension headers, not for the final 
payloads discussed in the previous subsection, the decompression of 
which is automatically stopped by the end of the packet. 


D... X "E m bo By Oe), 
4-——4---4---4---4---4---4---4---4 
| de Joëch ss. EID |NH | 
4-——4---4---4---—4---4---4---4---4 


Figure 4: NHC Byte for Extension Header GHC 
3.3. Indicating GHC Capability 


The 6LOWPAN baseline includes just [RFC4944], [RFC6282], and 
[RFC6775] (see [Roadmap-6LoWPAN]). To enable the use of GHC towards 
a neighbor, a 6LOWPAN node needs to know that the neighbor implements 
it. While this can also simply be administratively required, a 
transition strategy as well as a way to support mixed networks is 
required. 


One way to know that a neighbor does implement GHC is receiving a 
packet from that neighbor with GHC in it ("implicit capability 
detection"). However, there needs to be a way to bootstrap this, as 
nobody would ever start sending packets with GHC otherwise. 


To minimize the impact on [RFC6775], we define a Neighbor Discovery 

(ND) option called the 6LOWPAN Capability Indication Option (6CIO), 

as illustrated in Figure 5. (For the fields marked by an underscore 
in Figure 5, see Section 3.4.) 


0 d 2 3 
HA 2 34S Oe 78D. OT 2.3 4.5 6.7 8:9 0.1.2 3 4 5 6. 7.8 9. 0.1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length = 1 | |G| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 5: 6LOWPAN Capability Indication Option (6CIO) 


The G bit indicates whether the node sending the option is GHC 
capable. 


Once a node receives either an explicit or implicit indication of GHC 
capability from another node, it may send GHC-compressed packets to 
that node. Where that capability has not been recently confirmed, 
similar to the way Packetization Layer Path MTU Discovery (PLPMTUD) 
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[RFC4821] finds out about changes in the network, a node SHOULD make 
use of Neighbor Unreachability Detection (NUD) failures to switch 
back to basic 6LOWPAN header compression [RFC6282]. 


3.4. Using the 6CIO 


The 6CIO will typically only be sent in 6LOWPAN-ND Router 
Solicitation (RS) packets (which cannot themselves be GHC compressed 
unless the host desires to limit itself to talking to GHC-capable 
routers). The resulting 6LOWPAN-ND Router Advertisement (RA) can 
then already make use of GHC and thus indicate GHC capability 
implicitly, which in turn allows both nodes to use GHC in the 
6LOWPAN-ND Neighbor Solicitation / Neighbor Advertisement (NS/NA) 
exchange. 


The 6CIO can also be used for future options that need to be 
negotiated between 6LOWPAN peers; an IANA registry is used to assign 
the flags. Bits marked by underscores in Figure 5 are unassigned and 
available for future assignment. They MUST be sent as zero and MUST 
be ignored on reception until assigned by IANA. Length values larger 
than 1 MUST be accepted by implementations in order to enable future 
extensions; the additional bits in the option are then deemed 
unassigned in the same way. For the purposes of the IANA registry, 
the bits are numbered in most-significant-bit-first order from the 
16th bit of the option onward: the 16th bit is flag number 0, the 
3lst bit (the G bit) is flag number 15, up to the 63rd bit for flag 
number 47. (Additional bits may also be used by a follow-on version 
of this document if some bit combinations that have been left 
unassigned here are then used in an upward-compatible manner.) 


Flag numbers 0 to 7 are reserved for experimental use. They MUST NOT 
be used for actual deployments. 


Where the use of this option by other specifications or for 
experimental use is envisioned, the following items have to be kept 
in mind: 


o The option can be used in any ND packet. 


o Specific bits are set in the option to indicate that a capability 
is present in the sender. (There may be other ways to infer this 
information, as is the case in this specification.) Bit 
combinations may be used as desired. The absence of the 
capability indication is signaled by setting these bits to zero; 
this does not necessarily mean that the capability is absent. 
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4. 


o The intention is not to modify the semantics of the specific ND 
packet carrying the option but to provide the general capability 
indication described above. 


o Specifications have to be designed such that receivers that do not 
receive or do not process such a capability indication can still 
interoperate (presumably without exploiting the indicated 
capability). 


o The option is meant to be used sparsely, i.e., once a sender has 
reason to believe the capability indication has been received, 
there is no longer a need to continue sending it. 


IANA Considerations 
IANA has added the assignments listed in Figure 6 in the "LOWPAN NHC 


Header Type" registry (under "IPv6 Low Power Personal Area Network 
Parameters"). 


10110EEN: Extension header GHC [RFC7400] 
11010CPP: UDP GHC [RFC7400] 
11011111: ICMPv6 GHC [RFC7400] 


Figure 6: IANA Assignments for the NHC Byte 


IANA has allocated ND option number 36 for the "6LoWPAN Capability 
Indication Option (6CIO)" ND option format in the "IPv6 Neighbor 
Discovery Option Formats" registry [RFC4861]. 


IANA has created a subregistry for "6LoWPAN capability Bits" under 
the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" 
registry. The bits are assigned by giving their numbers as small, 
non-negative integers as defined in Section 3.4, in the range 0-47. 
The policy is "IETF Review" or "IESG Approval" [RFC5226]. The 
initial content of the registry is as shown in Figure 7: 


0-7: Reserved for Experimental Use [RFC7400] 
8-14: Unassigned 
15: GHC capable bit (G bit) [RFC7400] 


16-47: Unassigned 


Figure 7: IANA Assignments for the 6LoWPAN Capability Bits 
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Security Considerations 


The security considerations of [RFC4944] and [RFC6282] apply. As 
usual in protocols with packet parsing/construction, care must be 
taken in implementations to avoid buffer overflows and, in particular 
(with respect to the backreferencing), out-of-area references during 
decompression. 


One additional consideration is that an attacker may send a forged 
packet that makes a second node believe a third victim node is GHC 
capable. If it is not, this may prevent packets sent by the second 
node from reaching the third node (at least until robustness features 
such as those discussed in Section 3.3 kick in). 


No mitigation is proposed (or known) for this attack, except that a 
victim node that does implement GHC is not vulnerable. However, with 
unsecured ND, a number of attacks with similar outcomes are already 
possible, so there is little incentive to make use of this additional 
attack. With secured ND, the 6CIO is also secured; nodes relying on 
secured ND therefore should use the 6CIO bidirectionally (and limit 
the implicit capability detection to secured ND packets carrying GHC) 
instead of basing their neighbor capability assumptions on receiving 
any kind of unprotected packet. 


As with any LZ77 scheme, decompression bombs (compressed packets 
crafted to expand so much that the decompressor is overloaded) are a 
problem. An attacker cannot send a GHC decompressor into a tight 
loop for too long, because the MTU will be reached quickly. Some 
amplification of an attack from inside the compressed link is 
possible, though. Using a constrained node in a constrained network 
as a DoS attack source is usually not very useful, though, except 
maybe against other nodes in that constrained network. The worst 
case for an attack to the outside is a not-so-constrained device 
using a (typically not-so-constrained) edge router to attack by 
forwarding out of its Ethernet interface. The worst-case 
amplification of GHC is 17, so an MTU-size packet can be generated 
from a 6LoWPAN packet of 76 bytes. The 6LoWPAN network is still 
constrained, so the amplification at the edge router turns an entire 
250 kbit/s 802.15.4 network (assuming a theoretical upper bound of 
225 kbit/s throughput to a single-hop adjacent node) into a 

3.8 Mbit/s attacker. 


The amplification may be more important inside the 6LoWPAN, if there 
is a way to obtain reflection (otherwise, the packet is likely to 
simply stay compressed on the way and do little damage), e.g., by 
pinging a node using a decompression bomb, somehow keeping that node 
from re-compressing the ping response (which would probably require 
something more complex than simple runs of zeroes, so the worst-case 
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6. 


6. 


amplification is likely closer to 9). Or, if there are nodes that do 
not support GHC, those can be attacked via a router that is then 
forced to decompress. 


All these attacks are mitigated by some form of network access 
control. 


In a 6LoWPAN stack, sensitive information will normally be protected 
by transport- or application-layer (or even IP-layer) security, which 
are all above the adaptation layer, leaving no sensitive information 
to compress at the GHC level. However, a 6LoWPAN deployment that 
entirely depends on Media Access Control (MAC) layer security may be 
vulnerable to attacks that exploit redundancy information disclosed 
by compression to recover information about secret values. The 
attacker would need to be in radio range to observe the compressed 
packets. Since compression is stateless, the attacker would need to 
entice the party sending the secret value to also send some value 
controlled (or at least usefully varying and knowable) by the 
attacker in (what becomes the first adaptation-layer fragment of) the 
same packet. This attack is fully mitigated by not exposing secret 
values to the adaptation layer or by not using GHC in deployments 
where this is done. 
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Appendix A. Examples 


This section demonstrates some relatively realistic examples derived 
from actual packet captures taken at previous interops. 


For the Routing Protocol for Low-Power and Lossy Networks (RPL) 
[RFC6550], Figure 8 shows a Destination-Oriented Directed Acyclic 
Graph (DODAG) Information Solicitation (DIS), a quite short RPL 
message that obviously cannot be improved much. 


IP header: 
60 00 00 00 00 08 3a ff fe 80 00 00 00 00 00 00 
02 1c da ff fe 00 20 24 ff 02 00 00 00 00 00 00 
00000000000 00 00 00 1a 

Payload: 
9b 00 6b de 00 00 00 00 

Dictionary: 
fe 80 00 00 00 00 00 00 02 1c da ff fe 00 20 24 
ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 la 
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 

copy: 04 9b 00 6b de 

4 nulls: 82 

Compressed: 
04 9b 00 6b de 82 

Was 8 bytes; compressed to 6 bytes, compression factor 1.33 


Figure 8: A Simple RPL Example 


Figure 9 shows a RPL DODAG Information Object, a longer RPL control 
message that is improved a bit more. Note that the compressed output 
exposes an inefficiency in the simple-minded compressor used to 
generate it; this does not devalue the example, since constrained 
nodes are quite likely to make use of simple-minded compressors. 
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IP header: 
60 00 00 00 00 5c 3a ff fe 80 00 00 00 00 00 00 
02 lc da ff fe 00 30 23 ff 02 00 00 00 00 00 00 
00 00 00 00 00 00 00 la 
Payload: 
9b 01 7a 5f 00 fO 01 00 88 00 00 00 20 02 Od b8 
00 00 00 00 00 00 00 ff fe 00 fa ce 04 Oe 00 14 
09 ff 00 00 01 00 00 00 00 00 00 00 08 1e 80 20 
ff ff ff ff ff ff ff ff 00 00 00 00 20 02 Od Dë 
00 00 00 00 00 00 00 ff fe 00 fa ce 03 Oe 40 00 
ff ff ff ff 20 02 Od b8 00 00 00 00 
Dictionary: 
fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 
ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 la 
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 
copy: 06 9b 01 7a 5f 00 £0 
ref(9): 01 00 -> ref linnnkkk 0 7: c7 
copy: 01 88 
3 nulls: 81 
copy: 04 20 02 0d b8 
7 nulls: 85 
ref(60): ff fe 00 -> ref 101nssss O 7/11nnnkkk 1 1: a7 c9 
copy: 08 fa ce 04 0e 00 14 09 ff 
ref(39): 00 00 01 00 00 -> ref 101nssss 0 4/linnnkkk 3 2: a4 da 
5 nulls: 83 
copy: 06 08 1e 80 20 ff ff 
ref(2): ff ff -> ref ll1nnnkkk O 0: cO 
ref(4): ff ff ff ff -> ref llnnnkkk 2 0: dO 
4 nulls: 82 
ref(48): 20 02 0d b8 00.00 00 00 00 00 00 ff fe 00 fa ce 
-> ref 101nssss 1 4/11nnnkkk 6 0: b4 £0 
copy: 03 03 0e 40 
ref(9): 00 £f -> ref lilnnnkkk O 7: c7 
ref(28): ff ff ff -> ref 101nssss 0 3/linnnkkk 1 1: a3 c9 
ref(24): 20 02 0d b8 00 00 00 00 
-> ref 101nssss 0 2/11nnnkkk 6 0: a2 £0 
Compressed: 
06 9b 01 7a 5f 00 £0 c7 01 88 81 04 20 02 Od b8 
85 a7 c9 08 fa ce 04 0e 00 14 09 ff a4 da 83 06 
08 le 80 20 ff ff cO dO 82 b4 £0 03 03 Oe 40 c7 
a3 c9 a2 CU 
Was 92 bytes; compressed to 52 bytes, compression factor 1.77 


Figure 9: A Longer RPL Example 
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Similarly, Figure 10 shows a RPL Destination Advertisement Object 
(DAO) message. One of the embedded addresses is copied right out of 
the pseudo-header; the other one is effectively converted from global 
to local by providing the prefix FE80 literally, inserting a number 
of nulls, and copying (some of) the Interface Identifier part again 
out of the pseudo-header. Note that a simple implementation would 
probably emit fewer nulls and copy the entire Interface Identifier; 
there are multiple ways to encode this 50-byte payload into 27 bytes. 


IP header: 
60 00 00 00 00 32 3a ff 20 02 0d b8 00 00 00 00 
00 00 00 ff fe 00 33 44 20 02 0d b8 00 00 00 00 
00 00 00 ff fe 00 11 22 
Payload: 
9b 02 58 7d 01 80 00 £1 05 12 00 80 20 02 Od bü 
00 00 00 00 00 00 00 ff fe 00 33 44 06 14 00 80 
f1 00 fe 80 00 00 00 00 00 00 00 00 00 ff fe 00 
11:22 
Dictionary: 
20 02 Od b8 00 00 00 00 00 00 00 £f fe 00 33 44 
20 02 Od b8 00 00 00 00 00 00 00 ff fe 00 11 22 
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 
copy: 0c 9b 02 58 7d 01 80 00 £1 05 12 00 80 
ref(60): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 33 44 
-> ref 101nssss 1 5/11nnnkkk 6 4: b5 f4 
copy: 08 06 14 00 80 f1 00 fe 80 
9 nulls: 87 
ref(66): ff fe 00 11 22 -> ref 101nssss 0 7/1innnkkk 3 5: a7 dd 
Compressed: 
Oc 9b 02 58 7d 01 80 00 f1 05 12 00 80 b5 £4 08 
06 14 00 80 f1 00 fe 80 87 a7 dd 
Was 50 bytes; compressed to 27 bytes, compression factor 1.85 


Figure 10: A RPL DAO Message 
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Figure 11 shows the effect of compressing a simple ND neighbor 
solicitation. 


IP header: 
60 00 00 00 00 30 3a ff 20 02 Od b8 00 00 00 00 
00 00 00 ff fe 00 3b d3 fe 80 00 00 00 00 00 00 
02 1c da ff fe 00 30 23 
Payload: 
87 00 a7 68 00 00 00 00 fe 80 00 00 00 00 00 00 
02 1c da ff fe 00 30 23 01 01 3b d3 00 00 00 00 
1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24 
Dictionary: 
20 02 Od b8 00 00 00 00 00 00 00 ff fe 00 3b a3 
fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 
copy: 04 87 00 a7 68 
4 nulls: 82 
ref(40): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 
-> ref 101nssss 1 3/11nnnkkk 6 0: b3 £0 
copy: 04 01 01 3b a3 
4 nulls: 82 
copy: 02 1f 02 
5 nulls: 83 
copy: 02 06 00 
ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db 
copy: 02 20 24 
Compressed: 
04 87 00 a7 68 82 b3 £004 01 01 3b d3 82 02 1f 
02 83 02 06 00 a2 db 02 20 24 
Was 48 bytes; compressed to 26 bytes, compression factor 1.85 


Figure 11: An ND Neighbor Solicitation 
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Figure 12 shows the compression of an ND neighbor advertisement. 


IP header: 
60 00 00 00 00 30 3a fe fe 80 00 00 00 00 00 00 
02 1c da ff fe 00 30 23 20 02 Od b8 00 00 00 00 
00 00 00 ff fe 00 3b a3 
Payload: 
88 00 26 6c cO 0000 00 fe 80 00 00 00 00 00 00 
02 1c da ff fe 00 30 23 02 01 fa ce 00 00 00 00 
1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24 
Dictionary: 
fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 
20 02 Od b8 00 00 00 00 00 00 00 ff fe 00 3b a3 
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 
copy: 05 88 00 26 6c cO 
3 nulls: 81 
ref(56): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 
-> ref 101nssss 1 5/11nnnkkk 6 0: b5 £0 
copy: 04 02 01 fa ce 
4 nulls: 82 
copy: 02 1f 02 
5 nulls: 83 
copy: 02 06 00 
ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db 
copy: 02 20 24 
Compressed: 
05 88 00 26 6c c0 81 b5 £0 04 02 01 fa ce 82 02 
1f 02 83 02 06 00 a2 db 02 20 24 
Was 48 bytes; compressed to 27 bytes, compression factor 1.78 


Figure 12: An ND Neighbor Advertisement 
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Figure 13 shows the compression of an ND router solicitation. Note 
that the relatively good compression is not caused by the many zero 
bytes in the link-layer address of this particular capture (which are 
unlikely to occur in practice): 7 of these 8 bytes are copied from 
the pseudo-header (the 8th byte cannot be copied, as the universal/ 
local bit needs to be inverted). 


IP header: 
60 00 00 00 00 18 3a ff fe 80 00 00 00 00 00 00 
ae de 48 00 00 00 00 01 £f 02 00 00 00 00 00 00 
0000000000 00 00 00 02 
Payload: 
85 00 90 65 00 00 00 00 01 02 ac de 48 00 00 00 
00 01 00 00 00 00 00 00 
Dictionary: 
fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01 
ff 02 00 00 00 0000 0000 0000 00 00 00 00 02 
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 
copy: 04 85 00 90 65 
ref(11): 00 00 00 00 01 -> ref 11nnnkkk 3 6: de 
copy: 02 02 ac 
ref(50): de 48 00 00 00 00 01 
-> ref 101nssss 0 5/1l1nnnkkk 5 3: a5 eb 
6 nulls: 84 
Compressed: 
04 85 00 90 65 de 02 02 ac a5 eb 84 
Was 24 bytes; compressed to 12 bytes, compression factor 2.00 


Figure 13: An ND Router Solicitation 
Figure 14 shows the compression of an ND router advertisement. The 
indefinite lifetime is compressed to four bytes by backreferencing; 


this could be improved (at the cost of minor additional decompressor 
complexity) by including some simple runlength mechanism. 
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IP header: 
60 00 00 
10 34 00 
ae de 48 

Payload: 
86 00 55 
01 01 11 
ft EE SE 
00 00 00 
20 02 0d b8 
20 02 0d b8 

Dictionary: 
fe 80 00 00 
fe 80 00 00 
16 fe fd 17 

copy: 0c 86 

2 nulls: 80 

copy: 06 07 

4 nulls: 82 

copy: 06 03 

ref(2): 

ref (4): 

4 nulls: 

copy: 04 

12 nulls: 

copy: 04 

ref(38): 

copy: 01 

ref(24): 


00 
ff 
00 


c9 
22 
ff 
00 


82 
20 
8a 
20 
00 
e8 
20 
copy: 02 21 
ref(84): 


ref(40): 


ref(128): 


00 
fe 
00 


40 
00 
00 
00 
00 
00 


00 
00 
fe 


60 
00 
00 


00 
00 
00 
00 
00 
00 


00 
00 
fd 


3a 
T 
00 


Of 
00 
00 
00 
00 
00 


00 
00 
00 


ff 
22 
01 


a0 
00 
00 
00 
00 
00 


00 
00 
01 


fe 
fe 


Le 
03 
20 
20 
21 
00 


10 
ae 
00 
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80 
80 


00 
00 


00 
00 


00 
00 


5a 
04 
02 
02 
03 
00 


38 
40 
0d 
40 
00 
00 


E 
40 
b8 
10 
01 
EE 


00 
ff 
00 
00 
00 
fe 


34 
de 
00 


00 
48 
00 


EE 
00 
00 


fe 
00 
00 


00 
00 


00 
Bf 
00 
00 
00 
00 


00 
00 
01 


00 
00 


07 
ff 
00 
03 
00 
11 


11 
00 
00 


00 55 c9 40 00 Of a0 1c 5a 38 17 


dO 01 01 11 22 


04 40 40 ff ff 


02 


02 
00 


02 


03 


0d 


40 
03 


0d 


-> ref 101nssss 0 


Compressed: 


Oc 
do 
04 
£0 
Was 
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86 
01 
20 
02 
96 


00 55 c9 40 
01 11 22 82 
02 0d b8 8a 
21 03 a9 e6 
bytes; 


Figure 14: An ND Router Advertisement 


b8 


10 


-> ref 101nssss 0 4/11nnnkkk 1 3: 


b8 00 00 00 
-> ref 101nssss 0 2/11nnnkkk 6 O0: 


Ll 


15/11nnnkkk 3 3: 


00 
06 
04 


b3 cd 
compressed 


22 


Of 
03 
20 


ff ff -> ref linnnkkk 0 O0: 
ff ff ff ff => ref lilnnnkkk 2 O0: 


00 01 00 00 00 00 
-> ref l101nssss 0 9/11nnnkkk 
20 02 0d b8 00 00 00 
-> ref 101nssss 1 3/11nnnkkk 
ff fe 00 


a0 
04 
02 
af 
to 


cO 


00 


4 6: 


LL 


a2 TU 


a9 e6 
00 00 00 00 
b3 cd 


le 
40 
40 
db 
58 


do 


af db 


00 
00 


do 
ff 
00 
e8 
00 
22 


22 
01 
00 


5a 38 17 80 06 07 
40 ff ff cO dO 82 
10 a4 cb 01 e8 a2 


bytes, 
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compression factor 1.66 
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Figure 15 shows the compression of a DTLS application data packet 
with a net payload of 13 bytes of cleartext and 8 bytes of 
authenticator (note that the IP header is not relevant for this 
example and has been set to 0). This makes good use of the static 
dictionary and is quite effective crunching out the redundancy in the 
TLS PSK WITH AES 128 CCM 8 header, leading to a net reduction by 15 
bytes. 


IP header: 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 00 
Payload: 

17 fe fd 00 01 00 00 00 00 00 01 00 1d 00 01 00 

00 00 00 00 01 09 b2 Oe 82 cl 6e b6 96 c5 1f 36 

8d 17 61 e2 b5 d4 22 d4 ed 2b 
Dictionary: 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 
ref(13): 17 fe fd 00 01 00 00 00 00 00 01 00 

-> ref 101nssss 1 0/11nnnkkk 2 1: bü dl 
copy: 01 1d 
ref(10): 00 01 00 00 00 00 00 01 -> ref linnnkkk 6 2: £2 
copy: 15 09 b2 Oe 82 cl 6e b6 96 c5 1f 36 8d 17 61 e2 
copy: b5 d4 22 d4 ed 2b 
Compressed: 

bU dl 01 1d £2 15 09 b2 Oe 82 cl 6e b6 96 c5 1f 

36 8d 17 61 e2 b5 d4 22 d4 ed 2b 
Was 42 bytes; compressed to 27 bytes, compression factor 1.56 


Figure 15: A DTLS Application Data Packet 
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Figure 16 shows that the compression is slightly worse in a 
subsequent packet (containing 6 bytes of cleartext and 8 bytes of 
authenticator, yielding a net compression of 13 bytes). The total 
overhead does stay at a quite acceptable 8 bytes. 


IP header: 
00 00 00 00 00 00 00 00 00 00 00 00000 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 
Payload: 
17 fe fd 00 01 00 00 00 00 00 05 00 16 00 01 00 
00 00 00 00 05 ae a0 15 56 67 92 4d ff 8a 24 ei 
cb 35 bü 
Dictionary: 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 
ref(13): 17 fe fd 00 01 00 00 00 00 00 
-> ref 101nssss 1 0/11nnnkkk 0 3: bü c3 
copy: 03 05 00 16 
ref(10): 00 01 00 00 00 00 00 05 -> ref linnnkkk 6 2: f2 
copy: Oe ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 
Compressed: 
bU c3 03 05 00 16 £2 0e ae a0 15 56 67 92 4d ff 
8a 24 e4 cb 35 bü 
Was 35 bytes; compressed to 22 bytes, compression factor 1.59 


Figure 16: Another DTLS Application Data Packet 
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Figure 17 shows the compression of a DTLS handshake message, here a 


client hello. 


There is little that can be compressed about the 32 
the net reduction is by 14 bytes. 


51 52 ed 79 a4 20 c9 62 56 11 47 c9 
a4 fe c6 89 2f 32 26 9a 16 4e 31 7e 


00 
00 


00 
od 
a4 
00 


00 


00 
00 


36 
52 
fe 
00 


00 


00 
00 


01 
ed 
c6 
00 


00 


00 00 00 
00 00 01 00 00 


0 1/llnnnkkk 1 5: 


D 1/1l1nnnkkk 1 5: 


00 
00 


00 
79 
89 
02 


00 
00 


00 
00 


00 
a4 
2f 
cO 


00 
00 


23 2a fe fd 51 52 
39 ee 6c c0 a4 fe 
9f 20 92 92 81 05 


bytes, 


al cd 


al cd 


compression factor 1.26 


Handshake Packet 


bytes of randomness. Still, 
IP header: 
00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 
Payload: 
16 fe fd 00 00 00 00 00 00 00 00 
2a 00 00 00 00 00 00 00 2a fe fd 
20 c9 62 56 11 47 c9 39 ee 6c cO 
32 26 9a 16 4e 31 7e 9f 20 92 92 
a8 01 00 
Dictionary: 
00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 
16 fe fd 17 fe fd 00 01 00 00 00 
ref(16): 16 fe fd -> ref 101nssss 
9 nulls: 87 
copy: 01 36 
ref(16): 01 00 00 -» ref 101nssss 
copy: 01 2a 
7 nulls: 85 
copy: 23 2a fe fd 
copy: 39 ee 6c cO 
copy: 9f 20 92 92 
3 nulls: 81 
copy: 05 02 c0 a8 01 00 
Compressed: 
al cd 87 01 36 al cd 01 2a 85 
ed 79 a4 20 c9 62 56 11 47 c9 
c6 89 2f 32 26 9a 16 4e 31 7e 
02 c0 a8 01 00 
Was 67 bytes; compressed to 53 
Figure 17: A DTLS 
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